Next generation emergency call routing over diverse networks

ABSTRACT

Methods and systems for routing calls include determining media types within a received call for emergency services from a caller. Emergency service providers for the call are determined based on the determined media types. The call is routed to the emergency service providers, with different subsets of data within the call, corresponding to respective determined media types, being routed to different emergency service providers from the determined emergency service providers.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/702,905, filed on Sep. 13, 2017, which claims the benefit of U.S.Provisional Application Ser. No. 62/495,369, filed Sep. 13, 2016, bothof which are incorporated by reference herein in their entirety.

TECHNICAL FIELD

The present invention generally relates to the routing of emergencyinformation over diverse networks and, more specifically, to routingcalls, text, and other media over a variety of different networks in adynamic fashion that provides incremental migration from existingtechnologies.

BACKGROUND

The implementation emergency calling is antiquated, with manyjurisdictions being limited to telephone calls to an emergency number(such as 911) and sometimes limited Short Message Service (SMS) textmessages. Furthermore, the location-finding of existing technologies islimited, providing highly inaccurate location information in many cases.Citizens are increasingly interested in connecting to emergency servicesover a variety of media, including voice communications, text messages,internet messages (e.g., email), and video communications.

Transitioning to newer technologies for emergency services ischallenging, however. Traditional telecommunication providers have beenunable to ensure reliable delivery of citizens' requests for emergencyservices over a variety of telecommunications services. There are manytelecommunication providers providing a variety of services throughdiverse partners, each with its own unique set of capabilities,implementations, and contractual obligations. This diversity makes an adhoc system difficult to implement. Furthermore, even if onetelecommunication provider were to implement such a system, it would notnecessarily be available through other providers.

SUMMARY

A method for routing calls includes determining media types within areceived call for emergency services from a caller. Emergency serviceproviders for the call are determined based on the determined mediatypes. The call is routed to the emergency service providers, withdifferent subsets of data within the call, corresponding to respectivedetermined media types, being routed to different emergency serviceproviders from the determined emergency service providers.

A call routing system includes a hardware processor, an incominginterface configured to receive a call for emergency services from acaller through a communication service provider, and an outgoinginterface configured to send the call to a network having one or morecall destinations. A memory is configured to store one or more modulesthat, when executed by the hardware processor, perform an associatedfunction, including a routing module configured to identify media typeswithin the call, to determine emergency service providers for the callbased on the identified media types, and to route the call to theemergency service providers using the outgoing interface, with differentsubsets of data within the call, corresponding to respective determinedmedia types, being routed to different emergency service providers fromthe determined emergency providers.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings of the present invention can be readily understood byconsidering the following detailed description in conjunction with theaccompanying drawings, in which:

FIG. 1 is a block diagram of an emergency services call routing systemin accordance with an embodiment of the present invention;

FIG. 2 is a block/flow diagram of a method for emergency services callrouting in accordance with an embodiment of the present invention;

FIG. 3 is a block diagram of a next-generation emergency services callrouting system in accordance with an embodiment of the presentinvention; and

FIG. 4 is a block diagram of a processing system in accordance with anembodiment of the present invention.

It should be understood that the drawings are for purposes ofillustrating the concepts of the invention and are not necessarily theonly possible configuration for illustrating the invention. Tofacilitate understanding, identical reference numerals have been used,where possible, to designate identical elements that are common to thefigures.

DETAILED DESCRIPTION

Embodiments of the present invention provide next generation emergencycalling services to citizens whereby any communication service provider(CSP) can connect their services to a network that can reliably delivera citizen's request for emergency services to the appropriate callcenter, regardless of the CSP's network configuration, the request'smedia type, or the user's originating device.

Referring now to FIG. 1, an exemplary emergency communication system 100is shown. A user makes an emergency call using, for example, a mobiledevice 102. It should be understood that the use of a mobile device isintended to be purely exemplary and that any other communications meansmay be used instead, including for example a landline telephone, adesktop or portable computer, an appropriate radio service, a watch, apendant, a satellite communication service, and emergency serviceskiosks.

Furthermore, it should be understood that the “call” need not simply bevoice information, but may include text, video, and biometricinformation. For example, an emergency call could be made from awearable device that measures heart rate, blood sugar, blood oxygenlevels, or any of a variety of other biometrics. This information can betransmitted instead of, or in addition to, other types of media.Furthermore, different media can be directed to different recipients,for example with biometric information being sent directly to a doctorwhile the voice component gets sent to a dispatcher.

The user's device 102 interfaces with a CSP 104. In this particularexample, the CSP 104 may represent a cellular or digital telephoneservice provider, but it should be understood that the CSP 104 may beany organization that provides communication services to its citizensincluding, for example, internet service providers, landline telephoneproviders, radio relay providers, satellite communication providers,voice over IP providers, etc. It should be noted that the term IP standsfor “internet protocol” and is a general term that encompasses manyforms of computer networking.

More specifically, the CSP's network configuration could include 2G, 3G,4G, voice over long term evolution (VoLTE), TCP/IP, etc. and the mediatype could include, voice, SMS, instant messages, video, etc. The CSP104 accepts the call (or message) from the user's device 102 andrecognizes the call as being directed to emergency services. In onespecific embodiment the call may be a 911 call, but it should beunderstood that other emergency service systems and communications mediaare contemplated.

The CSP 104 then interfaces with next generation emergency services(NG911) routing system 106. The NG911 routing system 106 provides aflexible interface to CSPs 104 using a standard application programminginterface (API) for all types of communication. This allows the CSP 104to perform whatever internal technical handling may be needed for thecall and output a simple set of information about the call that NG911routing system 106 uses to ensure that the call is routed to theappropriate place. The NG911 system 106 detects the media type of thecall (e.g., voice, SMS, IP messaging, video, etc.) and provides a routethrough the an emergency service IP network (ESInet) 108 to a dispatcher110 that can handle the user's media type.

One particular service that is managed by the NG911 routing system 106is to acquire and verify user location information. Because userlocation is so important to providing timely and effective emergencyservices, different sources may be used, depending on the type of userdevice 102 and the type of call, to pinpoint the user's physicallocation. This location information is used to determine the closestdispatcher 110 to the user for routing purposes. Additional detailregarding the acquisition of location information will be providedbelow.

The NG911 routing system 106 interfaces with, e.g., an ESInet 108. Theterm ESInet is a general description of a communications network that isused for emergency services communications. ESInets are generallyresilient against disruption and highly redundant, providing uptimeguarantees of 99.999% or higher. There is no single specification forESInets, and it should be understood that any appropriate communicationsnetwork may be used instead. It should also be understood that lessresilient communications networks may be used instead, including forexample the Internet, thereby providing a wide variety of options forcommunicating with dispatchers.

In many cases, traditional ESInets are based on hardwired, voice-onlycircuits. It is specifically contemplated herein that such traditionalESInets may be used, but also that more modern services that employ IPor other networking protocols to dynamically route a wide variety ofinformation types may be used instead of, or in addition to, traditionalESInets. In cases where traditional ESInets are accessed, the NG911routing system 106 can translate from other call media into an analogvoice signal. For example, if a digital voice over IP call is received,the NG911 routing system can convert this call to analog voice signalsfor transmission over a traditional ESInet.

The call is passed to the ESInet 108 with routing information determinedby the NG911 routing system 106. The NG911 determines and provides bothan entry route and an ESInet route, the former of which validates andauthenticates access to the ESInet 108 and provides failover routes,while the latter further qualifies the incoming media and determinesmedia handling and location handling logic. The ESInet uses this routinginformation to connect the call, or pass the message, to a dispatcher110 (sometimes referred to as a public-safety answering point or PSAP).

The dispatcher 110 optionally communicates with the user 102 todetermine the nature of the emergency, to further verify the locationinformation, and to provide any information to the user 102 that may beneeded. The dispatcher 110 communicates with an emergency serviceprovider (e.g., police, fire, ambulance, etc.), providing theinformation from the call and the user's location.

Although the system 100 shown in FIG. 1 is made simple for the purposeof illustration, it should be understood that a realistic system mayinclude many user devices 102 for each CSP 104, many different CSPs 104using different technologies and communications standards, differentESInets 108 for different regions, and multiple different dispatchers110 for different types of emergency service. The 911NG routing system106 provides a single interface to all of these different uses,seamlessly and dynamically forwarding users' calls to the appropriatedestination, regardless of the type of media or technology beingemployed. Any CSP 104, providing any kind of communications service toits users 102, can interface with the NG911 routing system 106 toprovide emergency services to their users 102 without having toindependently create the interface with the ESInet 108.

In one example of how the system 100 can be used with more complicatedtopologies, the NG911 routing system 106 can establish connections withmultiple dispatchers 110 over multiple communications mediasimultaneously for a single call. Thus multiple dispatchers 110 canreceive updates over voice, video, or textual media and dispatchers 110can be added or removed from the call at any time.

The CSP 104 forwards calls to the NG911 routing system 106 using, forexample, a website, portal, or dedicated API. The NG911 routing system106 may maintain information regarding each CSP 104 locally, includinggeographical location, types of media provided by the CSP 104, servicesprovided by the CSP 104, and any technical, legal, or contractualrequirements the CSP 104 may have. This information may include adefault entry route, or the CSP 104 may provide entry route informationwith each call.

An exemplary entry route schema includes fields for <id>, <user_id>,<entry>, <description>, <direct_route>, and <location_failure_route>.The <user_id> field identifies the particular CSP 104 with a uniqueidentification number that is stored at the NG911 routing system 106.The purpose of the entry route is to authenticate requests for emergencyservices, to fully qualify and characterize an inbound request foremergency services, and to ensure that every request for emergencyservices gets routed to some form of call handler, regardless of mediatype. Every CSP 104 that provides some form of communication service toits users provides one or more entry routes to help manage emergencyservices for its users.

The <id> field represents a unique identifier for a given entry route.The NG911 routing system 106 may have many entry routes for respectiveCSPs 104, and in some cases may have multiple entry routes for each CSP104.

The <entry> field identifies entry route characteristics that describethe route by which the CSP 104 accesses the ESInet 108. The <entry>field may therefore include information regarding an internet address,communications technology, communications medium, etc. The <entry> fieldthereby provides access to the entry route and may include, e.g., aphone number or a setting in a header of a voice, video, or IP message.

The <description> field is a human-readable description provided by theCSP 104 for the entry route.

The <direct_route> field is a directive to the entry route in questionto skip intermediate location and subscriber lookup operations and toroute the call directly to the endpoint. This field may be used, forexample, for administrative or management lines that are not themselvescalling for emergency assistance.

The <location_failure_route> field may be used to indicate analternative route for the case where the NG911 routing system 106 cannotretrieve a location for the user 102, or finds a location that cannot beserved by an appropriate dispatcher 110. In one example, the<location_failure_route> may indicate a fallback 911 call center. Itshould be understood that it is a goal of the present embodiments tomake such failures rare, and so the use of a fallback route shouldtrigger logging to identify when the failure occurred and thecircumstances of the failure and should notify the CSP 104 and anyappropriate contact for the emergency service in question.

Assuming the call path has not been redirected by the <direct_route>field in the entry route, the NG911 routing system 106 queries an ESInetroute for additional routing information. The ESInet route may includefields such as <id>, <user_id>, <name>, <esinet_id>, <esinet_media_id>,<esinet_jurisdiction_id>, <esinet_entry_route_id>,<esinet_route_location_acquisition_rule_id>, <status>,<location_callback_function>,<location_callback_function_maximum_wait_seconds>,<subscriber_address_callback_function>,<subscriber_name_callback_function>, and<incident_additional_information_callback_function>. The ESInet routeinformation is set by a CSP 104 to establish how that particular CSPwill further qualify a request for emergency services. ESInet routesprovide additional routing instructions to a request regardless if thatrequest has originated as voice, video, or textual information. Afterthe call has been authenticated, qualified, and characterized by theentry route, the ESInet route further handles the call to ensuredelivery to a dispatcher 110.

The information in the ESInet route is selected based on its associationwith an entry route and based on the inbound media type. Once the routeis identified, the best location acquisition method for the user 102 isselected. Additional information about the user 102 can be bundled withthe call as well, such as the user's name, address, or informationrelating to the emergency incident.

The <user_id> field may again refer to the CSP's unique identificationnumber, as set in the entry route information.

The <name> field identifies the name that the CSP 104 has identifiedwith the route.

The <esinet_id> field is an identifier for the particular ESInet 108that the route belongs to. As noted above, there may be many differentESInets 108 that interface with the NG911 routing system 106.

The <esinet_media_id> field designates the type of media that isdelivered by the CSP 104 on the route. The media type (e.g., voice,text, video, etc.) affects media delivery rules. While most dispatchers110 are capable of handling voice information, many are only able tohandle communications through telephone company circuits, not IP voicecommunication. Furthermore, dispatchers 110 are not frequently capableof handling video or SMS or instant message text information. Asdispatchers 110 continue to implement more modern communicationtechnologies, this field allows the NG911 routing system 106 to selectdispatchers 110 that are capable of receiving the message.

The <esinet_jurisdiction_id> field optionally allows CSPs 104 to createroutes that forward calls directly to a jurisdiction. In someembodiments, the “jurisdictions” may refer to emergency services callcenters (e.g., 911 call centers). A given geographic region may bedivided into jurisdiction, with various call centers sharing theresponsibility of handling calls in the region. Most inbound callsrequesting emergency services are routed based on the location of thecaller and the jurisdiction serviced by the call center. However, thereare cases where a particular ESInet route may direct the call to aspecific destination, overriding the caller's location. The<esinet_jurisdiction_field> is used for this case, to direct the call toa specific destination.

The <esinet_entry_route_id> field specifies the identifier of a specificentry route. Every ESInet route should be associated with at least oneentry route.

The <esinet_route_location_acquisition_rule_id> field is used todesignate the type of location acquisition rule that will be used todetermine the user's location, if the location is not included with thecall. Exemplary options for this field include “landline,” “wirelesssector,” “wireless IP,” “voice over IP,” “IP,” and “SMS.”

The <status> field provides the status of the route, with exemplaryoptions for the field including “develop,” “test,” “stage,” and “live.”It should be noted that only live routes should be used to route actualemergency calls.

The <location_callback_function> field is used to locate the user 102 bylatitude and longitude. When location is not included with the call, theNG911 routing system 106 will use a location callback function providedby the CSP 104 to retrieve location information from the CSP'sdesignated API endpoint.

The <location_callback_function_maximum_wait_seconds> field designateshow long the NG911 routing system 106 should wait to receive userlocation information before it falls back to the<location_failure_route>. As noted above, the NG911 routing system 106will automatically notify the CSP 104 and a contact at the pertinentemergency service of this type of failure so that corrective action canbe taken.

The <subscriber_address_callback_function> field is used for the user'sphysical address. When the user's physical address is not included withthe call, the NG911 routing system 106 will use an address callbackfunction provided by the CSP 104 to retrieve the user's physicaladdress. Physical addresses can be provided by some landline serviceproviders as well as some voice over IP service providers.

The <subscriber_name_callback_function> field is used to retrieve thename of the user. When the user's name is not included with the call,the NG911 routing system 106 will use a subscriber name callbackfunction provided by the CSP 104 to retrieve the user's name. The callshould not be delayed while waiting to retrieve a user's name, but afailure of the callback function may be reported to both the CSP 104 andthe contact for the emergency service.

The <subscriber_additional_information_callback_function> field is usedto retrieve any additional information that may be available regardingthe user's situation. When additional information is not included withthe call, the NG911 routing system 106 will use an additionalinformation callback function provided by the CSP 104 to retrieve suchinformation. The call should not be delayed while waiting to retrieveadditional information, but a failure of the callback function may bereported to both the CSP 104 and the contact for the emergency service.

Referring now to FIG. 2, a method for emergency call handing is shown.Block 202 receives an initiating message using, e.g., the sessioninitiation protocol (SIP), from the CSP 104 to initiate the emergencycall. As noted above, this may reflect any sort of emergencycommunication from any of a variety of different types of CSP 104. Block204 then determines if the initiating message itself includes locationinformation for the user 102.

If the initiating message does not include location information, block206 queries the CSP 104 using the provided location callback function.Block 208 then determines whether the CSP 104 has provided suitablelocation information. If not, block 210 routes the call on the failureroute defined by the entry route. If the initiating message includes thelocation information, or if the CSP provides the location information,block 212 performs location validation.

Once the location has been validated, block 214 determines whether thecall can be routed to an appropriate dispatcher 110. If not, block 210routes to the failure route. If so, block 216 determines the dispatcher110 that is closest to the user 102 and block 218 routes the call andany other information that has been collected to the dispatcher 110.

The location validation of block 212 can take any of several forms,according the type and medium of the call. Location validation can makeuse of a variety of information sources including, e.g., postal servicedatabases, phonebook databases, CSP-provided subscriber addressdatabases, CSP-provided tower location databases, etc. Block 212determines, based on the type and medium of the call, how precise theassociated location information can be.

For example, if the call originates from a landline with a fixedaddress, the landline's location may be validated as a street address.If the call originates from a wireless device (e.g., a mobile phone),then a longitude or latitude provided is only validated as referring tothe location of the cell tower, with the possible inclusion of the cellsector. If the call originates from a wireless internet device (e.g.,through a home wireless local area network connection), then thelocation may be validated as a latitude and longitude. If the calloriginates from a voice over IP service, the location may be validatedas either a street address or as a latitude and longitude. If the calloriginates from an IP service (e.g., email or some other IPnetwork-bound communication), then the location may be validated as thelatitude and longitude of the subscriber. If a message originates as anSMS text message, then the message may be validated as an address of awireless tower and a cell sector.

The question of validation is tied together with the question of whethera call is routable. For example, a call location that is validated ascoming from a particular IP address may not be routable to anappropriate dispatcher 110. This may be due to the fact that thegeographic area encompassed by the possible locations with the IPaddress is so large that an appropriate dispatcher 110 cannot bedetermined or may be due to the impracticality of locating the userwithin that area. An exemplary list address types that can be properlyrouted includes static subscriber addresses, static cell antennaaddresses, static cell antenna latitude/longitude coordinates, andactual subscriber latitude/longitude coordinates. Thus, if for example alandline call comes in with a static subscriber address, no locationupdate is needed. However, wireless or IP calls may need furtherlocation information before the call can be properly routed to adispatcher 110.

Embodiments described herein may be entirely hardware, entirely softwareor including both hardware and software elements. In a preferredembodiment, the present invention is implemented in software, whichincludes but is not limited to firmware, resident software, microcode,etc.

Embodiments may include a computer program product accessible from acomputer-usable or computer-readable medium providing program code foruse by or in connection with a computer or any instruction executionsystem. A computer-usable or computer readable medium may include anyapparatus that stores, communicates, propagates, or transports theprogram for use by or in connection with the instruction executionsystem, apparatus, or device. The medium can be magnetic, optical,electronic, electromagnetic, infrared, or semiconductor system (orapparatus or device) or a propagation medium. The medium may include acomputer-readable storage medium such as a semiconductor or solid statememory, magnetic tape, a removable computer diskette, a random accessmemory (RAM), a read-only memory (ROM), a rigid magnetic disk and anoptical disk, etc.

Each computer program may be tangibly stored in a machine-readablestorage media or device (e.g., program memory or magnetic disk) readableby a general or special purpose programmable computer, for configuringand controlling operation of a computer when the storage media or deviceis read by the computer to perform the procedures described herein. Theinventive system may also be considered to be embodied in acomputer-readable storage medium, configured with a computer program,where the storage medium so configured causes a computer to operate in aspecific and predefined manner to perform the functions describedherein.

A data processing system suitable for storing and/or executing programcode may include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code to reduce the number of times code is retrieved frombulk storage during execution. Input/output or I/O devices (includingbut not limited to keyboards, displays, pointing devices, etc.) may becoupled to the system either directly or through intervening I/Ocontrollers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modem and Ethernet cards are just a few of thecurrently available types of network adapters.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

Reference in the specification to “one embodiment” or “an embodiment” ofthe present invention, as well as other variations thereof, means that aparticular feature, structure, characteristic, and so forth described inconnection with the embodiment is included in at least one embodiment ofthe present invention. Thus, the appearances of the phrase “in oneembodiment” or “in an embodiment”, as well any other variations,appearing in various places throughout the specification are notnecessarily all referring to the same embodiment.

It is to be appreciated that the use of any of the following “/”,“and/or”, and “at least one of”, for example, in the cases of “A/B”, “Aand/or B” and “at least one of A and B”, is intended to encompass theselection of the first listed option (A) only, or the selection of thesecond listed option (B) only, or the selection of both options (A andB). As a further example, in the cases of “A, B, and/or C” and “at leastone of A, B, and C”, such phrasing is intended to encompass theselection of the first listed option (A) only, or the selection of thesecond listed option (B) only, or the selection of the third listedoption (C) only, or the selection of the first and the second listedoptions (A and B) only, or the selection of the first and third listedoptions (A and C) only, or the selection of the second and third listedoptions (B and C) only, or the selection of all three options (A and Band C). This may be extended, as readily apparent by one of ordinaryskill in this and related arts, for as many items listed.

Referring now to FIG. 3, a block diagram of the NG911 routing system 106is shown. The NG911 routing system 106 includes a hardware processor 302and memory 304. The routing system 106 also includes one or morefunctional modules that may, in some embodiments be implemented assoftware that is executed in the processor 302 and stored in the memory304. In alternative embodiments, the functional modules may beimplemented as one or more discrete hardware components in the form of,e.g., application specific integrated chips and field programmable gatearrays.

The routing system 106 includes a CSP interface 306 and an ESInetinterface 308. Each interface includes a hardware communicationsinterface that may include any appropriate communications mechanismincluding, e.g., a wired or wireless network interface. The CSPinterface 306 communicates with CSP 104, receiving call information froma user 102. The CSP interface 306 furthermore sends queries back to theCSP 104, acquiring information relating to the user's location and anyother pertinent data using callback functions provided by the CSP 104.The ESInet interface 308 sends the call to an appropriate dispatcher 110through the ESInet 108. It should be understood that the CSP interface306 may communicate with multiple CSPs 104 and that the ESInet interface308 may communicate with multiple ESInets 108. Indeed, it isspecifically contemplated that the NG911 routing system may serve manyCSPs 104 and many ESInets 108, providing a standard gateway for theusers of different CSPs 104 to access any needed ESInet 108.

The NG911 includes an ESInet database 310 that includes informationregarding ESInet routing protocols and the dispatchers 110 that areserved thereby. The ESInet database 310 in particular includesinformation relating to the nature of the services provided by thedispatchers 110, the geographic area serviced by the dispatchers 110,and any technical routing information needed to reach each dispatcher110 through the ESInet(s) 108.

A location module 312 acquires and verifies location information foreach calling user 102. If the initial information provided by the CSP104 does not include location information, the location module 312 mayquery the CSP 104 via the CSP interface module 306 using theCSP-provided location callback function to obtain such information. Thelocation module 312 furthermore assesses the call, determining theprecision of the location based on the type of call. For example, unlessexplicit GPS information is provided, a call from a mobile telephone canoften only be traced to the closest tower that is serving the call.

A routing module 314 analyzes the call received by the CSP interfacemodule 306 and uses the location information provided by the locationmodule 312 to determine a dispatcher 110 in the ESInet database 310. Therouting module 314 then routes the call through the ESInet interfacemodule 308 to the appropriate ESInet 108 with routing information toread the appropriate dispatcher 110. It should also be noted that therouting module 314 provides fallback routing in the event that thelocation module 312 is unable to acquire or validate usable locationinformation for the user. In this case, the routing module 314 providesrouting according to the <location_failure_route> stored in thepertinent entry route entry of the ESInet database 310.

In some embodiments, the routing module 314 may route the call, or partsof the call, to multiple different destinations. For example, anemergency call that includes both voice and biometric information may berouted to an emergency dispatcher and directly to medical professionals.Thus, a diagnosis may be possible immediately (e.g., in the case of aheart attack) and the emergency services that are dispatched can beproperly equipped and informed. Thus the routing module 314 considersthe type of media making up the call, with exemplary media includingvoice data, SMS text messaging, instant messaging, video data, andbiometric data.

Referring now to FIG. 4, an exemplary processing system 400 is shownwhich may represent the NG911 routing system 106. The processing system400 includes at least one processor (CPU) 404 operatively coupled toother components via a system bus 402. A cache 406, a Read Only Memory(ROM) 408, a Random Access Memory (RAM) 410, an input/output (I/O)adapter 420, a sound adapter 430, a network adapter 440, a userinterface adapter 450, and a display adapter 460, are operativelycoupled to the system bus 402.

A first storage device 422 and a second storage device 424 areoperatively coupled to system bus 402 by the I/O adapter 420. Thestorage devices 422 and 424 can be any of a disk storage device (e.g., amagnetic or optical disk storage device), a solid state magnetic device,and so forth. The storage devices 422 and 424 can be the same type ofstorage device or different types of storage devices.

A speaker 432 is operatively coupled to system bus 402 by the soundadapter 430. A transceiver 442 is operatively coupled to system bus 402by network adapter 440. A display device 462 is operatively coupled tosystem bus 402 by display adapter 460.

A first user input device 452, a second user input device 454, and athird user input device 456 are operatively coupled to system bus 402 byuser interface adapter 450. The user input devices 452, 454, and 456 canbe any of a keyboard, a mouse, a keypad, an image capture device, amotion sensing device, a microphone, a device incorporating thefunctionality of at least two of the preceding devices, and so forth. Ofcourse, other types of input devices can also be used, while maintainingthe spirit of the present principles. The user input devices 452, 454,and 456 can be the same type of user input device or different types ofuser input devices. The user input devices 452, 454, and 456 are used toinput and output information to and from system 400.

Of course, the processing system 400 may also include other elements(not shown), as readily contemplated by one of skill in the art, as wellas omit certain elements. For example, various other input devicesand/or output devices can be included in processing system 400,depending upon the particular implementation of the same, as readilyunderstood by one of ordinary skill in the art. For example, varioustypes of wireless and/or wired input and/or output devices can be used.Moreover, additional processors, controllers, memories, and so forth, invarious configurations can also be utilized as readily appreciated byone of ordinary skill in the art. These and other variations of theprocessing system 500 are readily contemplated by one of ordinary skillin the art given the teachings of the present principles providedherein.

A number of implementations have been described. Nevertheless, it willbe understood that various modifications may be made. For example,elements of different implementations may be combined, supplemented,modified, or removed to produce other implementations. Additionally, oneof ordinary skill will understand that other structures and processesmay be substituted for those disclosed and the resulting implementationswill perform at least substantially the same function(s), in at leastsubstantially the same way(s), to achieve at least substantially thesame result(s) as the implementations disclosed. Accordingly, these andother implementations are contemplated by this disclosure and are withinthe scope of this disclosure.

The foregoing illustrates some of the possibilities for practicing theinvention. Many other embodiments are possible within the scope andspirit of the invention. It is, therefore, intended that the foregoingdescription be regarded as illustrative rather than limiting, and thatthe scope of the invention is given by the appended claims together withtheir full range of equivalents.

What is claimed is:
 1. A method for routing calls, comprising:determining a plurality of media types within a received call foremergency services from a caller; determining a plurality of emergencyservice providers for the call based on the determined plurality ofmedia types; and routing the receive call for emergency services to theemergency service providers, with different subsets of data within thecall corresponding to respective determined media types being routed todifferent emergency service providers from the determined plurality ofemergency service providers.
 2. The method of claim 1, furthercomprising routing the call to a fallback emergency service dispatcherresponsive to a determination that there is no emergency serviceprovider that has a geographic service area that includes the locationof the caller.
 3. The method of claim 1, wherein routing the call to theemergency service providers comprises routing call contents and thelocation information to the emergency service providers.
 4. The methodof claim 1, wherein routing the call to the emergency service providerscomprises routing the call over an emergency services IP network.
 5. Themethod of claim 1, wherein the plurality of media types include audioinformation and biometric information.
 6. The method of claim 5, whereinthe audio information is routed to an emergency service dispatcher andthe biometric information is routed to a doctor.
 7. The method of claim5, wherein the biometric information includes at least one type ofbiometric data selected from the group consisting of heart rate data,blood sugar data, and blood oxygen level data.
 8. The method of claim 1,wherein determining a plurality of emergency service providers for thereceived call based on the determined plurality of media types furthercomprises determining emergency service providers that are prepared tohandle each media type.
 9. A non-transitory computer readable storagemedium comprising a computer readable program for routing calls, whereinthe computer readable program when executed on a computer causes thecomputer to perform the steps of: determining a plurality of media typeswithin a received call for emergency services from a caller; determininga plurality of emergency service providers for the call based on thedetermined plurality of media types; and routing the call to theemergency service providers, with different subsets of data within thecall, corresponding to respective determined media types, being routedto different emergency service providers from the determined pluralityof emergency service providers.
 10. A call routing system, comprising: ahardware processor; an incoming interface configured to receive a callfor emergency services from a caller through a communication serviceprovider; an outgoing interface configured to send the call to a networkhaving one or more call destinations; and a memory configured to storeone or more modules that, when executed by the hardware processor,perform an associated function, including a routing module configured toidentify a plurality of media types within the call, to determine aplurality of emergency service providers for the call based on theidentified plurality of media types, and to route the call to theemergency service providers using the outgoing interface, with differentsubsets of data within the call, corresponding to respective determinedmedia types, being routed to different emergency service providers fromthe determined plurality of emergency providers.
 11. The system of claim10, wherein the routing module is further configured to route the callto a fallback destination responsive to a determination that there is nodestination that has a geographic service area that includes thelocation of the caller.
 12. The system of claim 10, wherein the routingmodule is further configured to route the call over an emergencyservices IP network.
 13. The system of claim 10, wherein the incominginterface is configured to receive calls from a plurality ofcommunication service providers and wherein the outgoing interfacemodule is configured to send calls to one or more of a plurality ofnetworks.
 14. The system of claim 10, wherein the plurality of mediatypes include audio information and biometric information.
 15. Thesystem of claim 14, wherein the audio information is routed to anemergency service dispatcher and the biometric information is routed toa doctor.
 16. The method of claim 14, wherein the biometric informationincludes one or more types of biometric data selected from the groupconsisting of heart rate data, blood sugar data, and blood oxygen leveldata.
 17. The system of claim 10, wherein the routing module is furtherconfigured to determine the plurality of emergency service providers fora call from the caller by determining emergency service providers thatare prepared to handle each media type.